Closes #467

This adds support for Python 3.14 and 3.14t as well as supporting free-threaded Python.

I've opted to add a threading.RLock member to the SoundFile object. I also made it so all the public methods of SoundFile that access the _file handle need to acquire the lock via a new with_lock decorator.

I'm using an RLock to avoid the need to refactor to avoid possibly reentrancy. I can probably use a threading.Lock instead but it will be trickier to get right.

Also adds tests for supported workflows (each thread has its own SoundFile) as well as unsupported workflows.

You could also support the free-threaded build without adding the locking. IMO the locking is a nicer user experience. With this approach if you try to use a SoundFile object in more than one thread simultaneously, you will see a RuntimeError if there is any concurrent use. Since I'm using the non-blocking variant of RLock.acquire(), it's impossible for this to introduce new scaling issues. Acquiring an uncontended lock is very low-overhead so I don't expect this to add much overhead.

I ran the tests under TSan and didn't see any issues besides a known race in BytesIO in 3.14 that should be fixed in 3.14.1. I can add TSan CI as a followup if you'd like.